I've been running Andrej Karpathy's LLM Wiki pattern for several months — reading sources, compiling them into a compounding, git-diffable wiki instead of re-deriving everything from scratch every session — and I'm a genuine convert. But two things kept nagging at me: query salience (finding the right page reliably, not just something plausible) and token economy (not re-reading half the wiki to answer one question).
Discover gists
A pattern for building personal knowledge bases using LLMs.
This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.
Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.
-
- #iot
- #chrome-and-friends: Chrome, V8, Blink, Mojo, etc.
- Linux kernel #todo
- expdev #todo
- fuzzing #todo
Audit this entire codebase for materially useful simplifications in its data structures, state representation, control flow, algorithms, and ownership.
This is an audit-only exercise. Do not edit files, run tests, implement recommendations, commit, or push. Read-only inspection commands are allowed.
You are the coordinator. Continue until the complete codebase has been reviewed and the final audit is validated.
- Establish the coverage contract
Inspect the repository and inventory every identifiable subsystem.
| Filter | Description | Example |
|---|---|---|
| allintext | Searches for occurrences of all the keywords given. | allintext:"keyword" |
| intext | Searches for the occurrences of keywords all at once or one at a time. | intext:"keyword" |
| inurl | Searches for a URL matching one of the keywords. | inurl:"keyword" |
| allinurl | Searches for a URL matching all the keywords in the query. | allinurl:"keyword" |
| intitle | Searches for occurrences of keywords in title all or one. | intitle:"keyword" |
自QQ用了新内核“NT”架构,原有的数据库解密方法也用不了了。查看新版QQ的文件结构可以发现它的新数据库文件:$HOME/.config/QQ/nt_qq_<ID>/nt_db/nt_msg.db。
我尝试在GitHub上全网搜索“nt_msg.db”,发现仅有两个相关的页面:
- https://github.com/Young-Lord/QQ-History-Backup/issues/9
- https://github.com/QQBackup/qq-win-db-key/blob/02623f5cd547865bbcddc9da5c0ed99584c87b15/nt%20qq%20win%20db%20%E6%95%99%E7%A8%8B.md
逆向不会搞。但得到了两个很有用的信息:key的长度为16,和密钥派生函数迭代次数为4000。并且看那上面有个打开SQLCipher的截图,密钥是直接输进去的,那就应都是可打印字符。我使用内存转储,把转储文件通过strings命令过滤出字符串,然后再筛选出16长度的行,这样就可以一个一个去试了。
这是试密码的程序:
